1. Field of the Invention
The present invention relates to the field of data storage systems. More specifically, embodiments of the present invention relate to methods and systems for providing automatic software versioning for controller units of a data storage system.
2. Related Art
FIG. 1A illustrates a system 10 that includes a host computer or server 12 that interfaces with a disk storage system 14. The disk storage system 14 is capable of storing large amounts of data, e.g., multiple terabytes, and is designed to operate with a high degree of reliability. One such storage system is the xe2x80x9cStarEdge T3 Arrayxe2x80x9d which is commercially available from Sun Microsystems, Inc., of Mountain View, Calif. To maintain the high degree of reliability and large storage capacity, fault tolerant storage system 16 is employed along with multiple redundant controller units 18a and 18b (which are also called xe2x80x9ca partner pairxe2x80x9d). The fault tolerant storage system may be a disk array subsystem. The disk array subsystem 16, contains an array of individual disk units arranged to provide redundancy. The controllers 18a-b operate in a master-slave fashion. The controller units 18a-b interface with the host system 12 and, in so doing, the controller units 18a-b allow the disk array subsystem 16 to be viewed by the host system 10 as one large single volume.
In the past, the software application 20 used by the controllers 18a-b was loaded into the disk array subsystem 16 and, upon booting, the controllers 18a-b would automatically download this software application into their respective volatile memories 22 and 24, e.g., random access memory (RAM). The application could then function to make the disk array subsystem 16 appear to the host system 10 as one single volume. Unfortunately, the process of downloading the application from the disk array subsystem 16 on each boot-up is very time consuming and therefore inefficient and error-prone.
FIG. 1B illustrates another system 26 having a similar complement of components as system 10, except the controllers 18a-18b are different. In this system, the controllers 18a-18b contain a respective non-volatile memory 32 and 34 which contains the software application described above. The benefit of this design 26 is that the application no longer needs to be loaded from the disk array subsystem 16 upon each boot. Rather, the application is directly accessed by each controller from its own internal non-volatile memory, e.g., 32 and 34. The use of non-volatile memory to serve this purpose increases the overall efficiency of the controllers 18a-b. 
A drawback of system 26 is that the version of the software used to control the controllers 18a-b is no longer associated with the disk system 14, but rather it becomes associated with each individual controller separately. This may lead to several potentially dangerous conditions. For example, a partner pair could have mutually exclusive software versions operating on the two controllers. This could lead to data integrity problems. This situation could occur if one controller was replaced (due to malfunction) and the replacement controller (in the typical case) contains a different software version from the remaining controller. Another example occurs when a controller is loaded into a system, which is configured to operate in an up-level software version, resulting in a conflict of software versions residing within the partner pair. Such version confusion can lead to data corruption or complete storage system failure.
Described herein are a method and system for performing computer controlled software versioning between multiple controllers in a storage system. The storage system includes a fault tolerant storage system and multiple redundant controllers that allow the disk array to be viewed as a large disk system by a host computer or server. The fault tolerant storage system has stored thereon a preferred version of software to be used by the controllers. This software may be updated by replacing the copy stored in the fault tolerant storage system. The controllers each contain non-volatile memory. On boot, a controller compares the software version in its non-volatile memory to the preferred version in the fault tolerant storage system. If they are different (e.g., the software on the fault tolerant storage system was updated or the controller was updated with a non-preferred software version), then the controller copies the disk array version into its non-volatile memory and then re-boots. One controller is typically left operational while the other is re-booted for redundancy. Computer controlled versioning allows: (1) lockstep software updates between the controllers based on a software version that is associated with (or tied to) the disk system as a whole; and (2) provides a central store from which the controllers may obtain the preferred software version.
A special flash update mechanism is also described with respect to an implementation that uses flash memory as the non-volatile memory. According to this method, each controller has two flash memories for level 2 and level 3 of its boot sequence. On boot, when level 1 of the boot sequence is booting, level 1 software is used to select the most recent valid version of the software stored on the two flash memories of level 2. That selected version is then used to boot level 2. Likewise, on boot, when level 2 is booting, level 2 software selects the most recent valid version of the software stored on the two flash memories of level 3. That selected version is then used to boot level 3. If no valid versions are available, then an error condition exists.
More specifically, embodiments of the present invention are directed toward a method of providing version control within a fault tolerant system having the follow steps: a) invoking a boot sequence of a first controller that is coupled to a storage system having stored thereon a preferred application version; b) during the boot sequence, comparing the preferred application version with a stored application version stored within a memory of the first controller; c) provided the stored application version is different from the preferred application version, storing the preferred application version into the memory and causing the first controller to re-boot to thereby execute the preferred application version after re-boot; and d) provided the stored application version is the same as the preferred application version, causing the first controller to execute the stored application version. Embodiments also include the above and wherein the memory is a programmable non-volatile memory and wherein the memory is a flash memory and wherein the storage system is disk array system.
Embodiments also include the above and wherein step a) includes the following steps: a1) executing a first level wake-up boot sequence; a2) during the first level boot sequence, checking two application versions that are associated with a second level boot sequence and selecting a most recent valid version; and a3) executing the most recent valid version as the second level boot sequence. Embodiments also include a fault tolerant storage system implemented in accordance with the above.